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Abstract 

Interoperability  on  the  technical  level  is  a  hot  topic  since  several  decades.  Despite  the  fact  that 
several  technical  reference  models  to  increase  interoperability  have  been  introduced,  we  are  still 
waiting  for  working  solutions.  The  reason  may  be,  that  interoperability  is  definitely  not  limited  to 
the  technical  domain  but  is  dependent  on  organizational  aspects  as  well.  To  deal  with  these 
issues,  they  have  to  be  perceived  first.  The  recent  CCRTS  contributed  to  this  very  well.  To 
overcome  resulting  questions,  however,  the  influence  must  be  captured  in  a  reproducible  way  in 
form  of  measures  of  merit.  Based  on  the  experience  in  several  international  projects,  the  author 
developed  a  framework  to  deal  with  possible  measures  of  merits  to  be  used  to  deal  with  the 
various  layers  of  semantic  interoperability  in  coalition  operations. 

The  paper  introduces  this  reference  model,  connects  it  to  the  recent  discussions  of  measures  of 
merits  for  C2  Assessment,  and  introduces  some  contributions  to  the  discussions  of  measure  for 
interoperability  on  various  levels.  Furthermore,  some  technical  reference  models  will  be  mapped 
to  this  reference  model  to  show  that  actual  used  legacy  model  results  can  be  migrated,  hence 
reused  in  this  broader  context. 

1  Introduction 

The  crux  of  -  or  positively  stated,  the  challenge  for  -  the  interoperability  problem  is  the 
advent  of  Network  Centric  Warfare  (NCW).  NCW  is  about  networking  humans, 
organizations,  institutions,  services,  nation,  etc.,  and  the  related  organizational  behavior. 
NCW  is  not  about  technical  networks;  it  doesn’t  focus  on  technologies.  The  development 
of  doctrines  and  guidance  for  operations  using  NCW  is  part  of  the  institutional 
transformation  for  the  new  millennium.  While  the  technical  domain  is  an  important 
enabler,  the  social  components  and  the  processes  related  to  conducting  a  military 
operation  that  will  be  using  the  information  are  as  important  as  the  technical  ability  to 
interchange  the  data  related  to  this  information. 
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Furthermore,  the  relation  between  technical  and  operational  interoperability  is  neither 
proportional  nor  linear.  It  is  possible  that  two  commanders,  who  share  the  same 
command  and  control  facilities,  in  particular  having  the  same  C4ISR  system  support, 
make  decisions  that  are  contradictive  or  sub-optimal.  It  is  also  possible  that  two 
commanders  supported  by  C4ISR  systems  that  are  not  interoperable  on  the  technical  level 
are  fighting  very  well  together.  Therefore,  investing  in  technical  interoperability  not 
necessarily  leads  to  an  increase  in  operational  interoperability. 

These  observations  motivate  the  necessity  to  set  up  reference  model  for  measure  of 
merits  enabling  to  cope  with  this  in  a  reproducible  manner.  In  order  to  cope  with  these 
effects,  we  have  to  be  able  to  measure  them  effectively.  While  the  technical  reference 
models  (TRM)  are  only  sufficient  on  the  technical  level,  they  can  contribute  to  gaining  an 
understanding  how  various  layers  of  interoperability  can  be  dealt  with.  Therefore,  two  of 
the  TRM  in  use  or  under  development  are  presented  first  to  deal  with  the  technical  levels. 
Secondly,  some  existing  measures  of  merits  in  use  will  be  evaluated.  Thirdly,  some 
technical  models  being  useful  to  support  the  analysis  of  non-technical  interoperability 
issues  will  be  presented.  In  particular  modeling  techniques  can  support  dealing  with  the 
challenges  of  operational  interoperability.  The  main  idea  is  the  introduction  of  a 
Common  Operational  Model  instead  of  the  common  operational  picture  used  actually. 
Finally,  the  findings  will  be  combined  into  the  proposal  for  a  reference  model  of 
interoperability  for  technical  and  operational  levels. 

2  Technical  Reference  Models 

There  are  many  technical  reference  models  in  use  to  determine  the  interoperability  of 
technical  systems.  On  this  level,  interoperability  is  defined  as  the  ability  to  make  use  of 
functionality  offered  by  other  components  to  increase  the  functionality  offered  by  the 
own  system.  Although  technical  interoperability  is  not  sufficient  for  coalition 
interoperability,  is  facilitates  the  collaboration  if  you  are  able  to  share  information  using 
your  C4I  systems  and  other  information  technology  (IT)  support. 

The  IT  industry  with  the  support  of  academia  came  up  with  models  like  the  ISO/OSI 
seven-layer  model,  which  became  a  standard  with  general  networked  IT  solutions.  Based 
on  such  layered  approaches,  which  are  used  to  define  various  protocols  enabling 
interoperable  sharing  of  information  in  IT  systems,  the  military  community  defined  their 
reference  models  as  well.  In  the  light  of  coalition  interoperability,  two  models  will  be 
evaluated  further,  namely  the  “Level  of  Information  Systems  Interoperability”  model 
(LISI),  and  the  NATO  C3  Technical  Architecture  (NC3TA)  Reference  Model  for 
Interoperability  (NMI). 

2.1  Level  of  Information  System  Interoperability  LISI 

The  LISI  model  [1]  provides  a  reasonable  framework  to  scope  the  needed  level  of 
connectivity  in  the  domain  of  technical  interoperability.  LISI  is  established  by  the  U.S. 
DoD  C4SIR  Framework  Architecture  [2].  As  depicted  in  Figure  1,  LISI  identifies  four 
domains: 
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•  Procedures  and  Policy, 

•  Applications, 

•  Data,  and 

•  Infrastructure 


Every  one  of  the  PAID  domain  impacts  on  information  exchange,  in  other  words,  a  level 
of  interoperability  exists  within  each  of  the  PAID  domains. 


T.FVFT 

J 

Interoperabilit 

y  Attributes  | 

(Environment) 

P  rocedures 

.A^pplications 

Infrastructure 

Data 

Enterprise 

4 

c 

Multi-National 

Enterprises 

Interactive 

(eross 

applieations) 

Multi- 

Dimensional 

Topologies 

Cross- 

Enterprise 

Models 

Level 

b 

Federal 

Enterprise 

(Universal) 

a 

DoD  Enterprise 

Full  Objeet 

Cut  &  Paste 

Enterprise 

Model 

Domain 

3 

c 

b 

Domain 

Service/Agency 
Doctrine, 
Procedures, 
Training,  etc. 

Shared  Data 

(Situation  Displays 
Direct  DB  Exchanges) 

WAN 

DBMS 

Level 

Group  Collaboration 
(White  Boards,  VTC) 

Domain 

Models 

(Integrated) 

a 

Full  Text 

Cut  and  Paste 

Functional 

Level 

(Distributed) 

2 

c 

b 

Common 
Operating 
Environment 
(DII-COE 
Level  5) 
Complianee 

Web  Browser 

LAN 

Program 

Models 

and 

Advanced 

Data 

Formats 

Basic 

Operations 

(Documents,  Maps, 
Briefings,  Pictures 
Spreadsheets,  Data) 

a 

Program 

Standard  Procedures, 
Training,  etc. 

Advaneed 
Messaging 
(Parsers,  E-Mail+) 

Network 

Connected 

Level 

(Peer-to-Peer) 

1 

d 

Standards 

Compliant 

Basie  Messaging 
(Plain  Text,  E-mail  w/o 
attachments) 

Two  Way 

Basic 

Data 

Formats 

c 

(JTA,  IEEE) 

Data  File  Transfer 

b 

Seeurity 

Profile 

Simple  Interaetion 
Text  Chatter,  Voice, 
Fax,  Remote  Access, 
Telemetry) 

a 

One  Way 

Isolated 

Level 

(Manual) 

0 

d 

Media  Exehange 
Proeedures 

N/A 

Removable 

Media 

Media 

Formats 

c 

NATO 
Level  3 

Manual 

Re-entry 

Private 

Data 

b 

Manual 

Aeeess 

Controls 

NATO 
Level  2 

a 

NATO 
Level  1 

0 

No  Known  Intel 

roperability 

Figure  1:  The  Level  of  Information  System  Interoperability  (LISI)  Model 

The  resulting  technical  interoperability  is  measured  in  five  categories: 
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•  Level  0:  Isolated  (Manual)  -  Non-connected,  use  of  manual  gateways  (diskettes,  etc.) 

•  Level  1 :  Connected  (Peer-to-Peer)  -  Electronic  connection;  Separate  data  and  applications 

•  Level  2:  Functional  (Distributed)  -  Minimal  common  Functions;  Separate  data  and  applications 

•  Level  3 :  Domain  (Integrated)  -  Shared  data;  “Separate”  applications 

•  Level  4:  Enterprise  (Universal)  -  Interactive  manipulation;  Shared  Data  and  applications 

The  level  4  is  the  highest  level  of  technical  interoperability,  i.e.,  data  is  electronically  delivered  to  the 
Warfighter  regardless  what  access  method  he  uses  (from  handheld  to  C4I  workstations)  and  from  where  he 
uses  this  device.  He  can  just  plug  into  the  infosphere.  The  technical  vision  is  also  captured  in  the  Global 
Information  Grid  (GIG),  as  envisioned  in  U.S.  DoD  Directive  8I00.I  [3].  The  GIG  will  be  globally 
interconnected,  end-to-end  set  of  information  capabilities,  associated  processes,  and  personnel  for 
collecting,  processing,  storing,  disseminating  and  managing  information  on  demand  to  Warfighters,  policy 
makers,  and  support  personnel.  The  GIG  includes  all  owned  and  leased  communications  and  computing 
systems  and  services,  software  (including  applications),  data,  security  services,  and  other  associated 
services  necessary  to  achieve  Information  Superiority.  A  more  user-oriented  view  on  the  various  levels  of 
interoperability  is  given  in  Figure  2. 
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Figure  2:  Levels  of  Interoperability  proposed  by  LISI 

The  LISI  model  was  successfully  applied  to  deal  with  identifying  issues  of  technical 
interoperability  not  only  for  C4ISR  systems,  but  also  in  the  domain  of  C4I-to-M&S 
interoperability,  which  is  a  topic  that  becomes  viable  when  thinking  about  embedded 
training  and  M&S  support  to  operations.  This  topic  has  been  extensively  dealt  with  by 
study  groups  of  the  Simulation  Interoperability  Standards  Organizations.  Results  can  be 
found,  among  many  other  special  topic  papers,  in  the  reports  [4]  and  [5].  A  third  study 
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group  will  present  the  results  in  Fall  2003  during  the  Simulation  Interoperability 
Workshop. 

2.2  NATO  C3  Technical  Architecture  Reference  Model  for  Interoperability  (NMI) 

NATO  is  using  a  very  similar  model  to  LIST  It  is  comprised  in  the  NATO  Consultation, 
Command  and  Control  (C3)  Technical  Architecture  (NC3TA)  [6],  The  NC3TA  describes 
the  information  technology  (IT)  to  be  used  as  a  basis  for  common  NATO  systems.  It 
addresses  architectural  descriptions,  reference  models,  and  Off-The-Shelf  (OTS)- 
technologies.  Furthermore,  the  NC3TA  integrates  technical  aspects  of  specific 
architectures  or  frameworks  such  as  the  NATO  Information  Security  Framework. 

The  NC3TA  consists  of  five  volumes: 

•  Management, 

•  Architectural  Models  and  Description, 

•  Base  Standards  and  Profiles, 

•  NC3  Common  Standards  Profile  (CSP), 

•  NC3  Common  Operating  Environment  (COE). 

The  NC3TA  contains  five  technical  reference  models  of  interest  to  our  review  of 
C4ISR/M&S  interoperability: 

•  The  NC3TA  Technical  Reference  Model  (NTRM)  provides  the  conceptual 
framework  and  common  vocabulary  for  addressing  interoperability  and 
compatibility  among  NATO  information  systems.  It  sets  a  foundation  for  all  NC3 
technical  architectures. 

•  The  NATO  Common  Operating  Environment  (NCOE)  Component  Model 
(NCM)  instantiates  the  NTRM  and  models  the  NCOE  architecture.  In  turn,  the 
NCOE  aspires  to  define  a  plug  and  play  client/server  environment  [Volume  5]  to 
increase  interoperability,  reusability,  portability,  and  operational  capability  while 
reducing  development  time,  technical  obsolescence,  training  requirements,  and 
life  cycle  cost. 

•  The  NATO-Common-Funded  (NCF)  Reference  Models  for  Functional 
Configurations  (NFC)  refines  the  NCM.  This  set  of  reference  models  provides 
functional  configurations  as  building  blocks  for  developing  the  functional 
architecture  of  NCF  systems. 

•  The  NATO  Reference  Model  for  Open  Systems  Information  Interchange 
(NOSI)  focuses  on  communications  issues  not  covered  by  previous  models. 

•  The  NC3TA  Reference  Model  for  Interoperability  (NMI)  models  technical 
interoperability  by  leveraging  the  concept  of  degrees  of  interoperability. 
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Categories  of  elementary  services  form  a  descriptive  basis  for  functional 
interoperability  profiles. 

In  the  rest  of  this  section,  we  will  focus  the  evaluation  on  the  NMI  only.  Short 
descriptions  of  the  other  aspects  are  given  in  [5]  and  related  documents  published  by 
NATO. 

The  NC3TA  reference  model  for  interoperability  (NMI)  establishes  interoperability 
degrees  and  sub-degrees.  Interoperability  degrees  define  a  maturity  model  that  captures 
interoperability  sophistication.  Interoperability  sub-degrees  describe  a  capability  model 
that  reflects  available  functionality.  These  degrees  highlight  the  value  of  structuring  and 
automating  exchange  and  interpretation  of  data  to  enhance  operational  effectiveness.  The 
NMI  provides  definitions  for  interoperability  degrees  and  sub-degrees  and  presents 
interoperability  profiles.  The  NMI  classifies  interoperability  at  four  levels. 

•  Degree  1 :  Unstructured  Data  Exchange 

This  level  involves  the  exchange  of  human-interpretable,  unstructured  data  such 
as  the  free  text  found  in  operational  estimates,  analysis,  and  papers.  Sub-degrees 
are: 

-  Network  Connectivity, 

-  Basic  Document  Exchange,  and 

-  Basic  Informal  Message  Exchange. 

•  Degree  2:  Structured  Data  Exchange 

This  level  involves  the  exchange  of  human-interpretable  structured  data  intended 
for  manual  and/or  automated  handling,  but  requires  manual  compilation,  receipt, 
and/or  message  dispatch.  Sub-degrees  are: 

-  Enhanced  Informal  Message  Exchange, 

-  Enhanced  Document  Exchange, 

-  Network  Management, 

-  Map  Overlays/Graphics  Exchange, 

-  Directory  Services, 

-  Web  Access, 

-  Multi-Point  Applications,  and 

-  Data  Object  Exchange. 

•  Degree  3 :  Seamless  Sharing  of  Data 

This  level  involves  automated  data  sharing  within  systems  based  on  a  common 
exchange  model.  Sub-degrees  are: 

-  Formal  Message  Exchange, 

-  Common  Data  Exchange, 

-  System  Management, 

-  Secure  Systems  Management, 

-  Security  Management,  and 

-  Real-time  Data  Exchange. 
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•  Degree  4:  Seamless  Sharing  of  Information 

An  extension  of  degree  3,  this  level  establishes  universal  interpretation  of 
information  through  cooperative  data  processing.  Sub-degrees  are: 

-  Common  Information  Exchange,  and 

-  Distributed  Applications. 

Unconnected  systems,  which  would  represent  the  interoperability  level  of  degree  zero, 
are  not  mentioned  in  the  NATO  C3  Technical  Architecture.  The  Seamless  Sharing  of 
Information  (degree  3)  equals  the  Universal  Interoperability  Level  (level  4)  of  Enterprise 
Solutions  as  envisioned  in  LISI. 

Although  these  technical  interoperability  models  have  been  applied  successfully  in  the 
technical  domain,  they  are  limited  to  the  levels  of  technical  interoperability.  As  pointed 
out  before,  coalition  interoperability  comprises  of  technical  and  organizational 
interoperability  aspects.  However,  instead  of  reinventing  the  wheel  when  thinking  about 
a  framework  capable  of  dealing  with  all  aspects  of  coalition  interoperability  it  is 
recommended  to  reflect  the  findings  of  technical  reference  models  such  as  LISI  and  NMI. 

3  Using  Technical  Reference  Models  for  Non-technical  Interoperability  Issues 

There  is  even  more  use  to  technical  reference  models  than  just  dealing  with  technical 
interoperability  issues.  In  fact,  the  can  enable  the  efficient  exchange  of  information 
between  participating  experts  coming  from  various  expert  or  application  domains.  They 
can  establish  a  „common  language“  to  be  used  to  deal  with  the  issues  of  interoperability. 

To  deal  with  organizational  interoperability  above  the  technical  interoperability,  the 
domain  of  data  and  information  has  to  be  lifted  up  into  the  domain  of  knowledge  and 
awareness.  As  accepted  in  the  MORS  community,  data  in  context  leads  to  information, 
which  leads  to  knowledge  about  general  interrelations,  which  leads  to  awareness  of  what 
is  possible  in  a  given  situation.  The  delivering  of  data  and  generating  of  context  can  be 
supported  by  an  efficient  common  operational  picture  (COP)  delivered  by  an  enterprise 
like  distributed  C4ISR  framework,  which  is  technically  interoperable  as  much  as 
possible.  The  organizational  processes  of  gaining  knowledge  from  this  and  having 
situational  awareness  can  hardly  be  supported  by  today’s  C4ISR  systems  and  are  truly 
beyond  technical  interoperability.  However,  the  scientific  modeling  process  can  be  used 
to  gain  the  necessary  insights;  in  other  words,  the  use  of  models  is  perceived  to  be  of 
value  and  is  a  necessary  step  to  reach  coalition  interoperability  through  organizational 
interoperability  on  top  of  technical  interoperability. 

3.1  From  Common  Operational  Pictures  to  Common  Models  for  Operations 

The  necessity  to  build  models  when  designing  simulation  systems  is  without  question, 
but  why  is  modeling  also  very  important  for  systems  that  are  designed  to  support 
Command,  Control,  Communications,  Computers,  Intelligence,  Reconnaissance,  and 
Intelligence  (C4ISR),  in  particular  when  coalition  interoperability  is  required? 
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When  dealing  with  C4ISR,  it  is  often  assumed  that  we  are  not  dealing  with  new  and 
experimental  processes,  that  we  know  the  processes  and  can  very  well  communicate  the 
challenges  and  solutions,  hence  we  do  not  need  explicit  modeling.  In  addition,  it  is 
assumed  that  the  obtaining  of  necessary  information  is  sufficient  to  deal  with 
interoperability.  However,  reality  offers  another  view. 

Very  few  domains  of  military  applications  underwent  such  dramatic  changes  as  C4ISR 
did.  Due  to  a  rapidly  changing  and  challenging  environment,  highly  adaptive  processes 
had  to  be  developed.  This  happened  mostly  within  the  operation  itself,  as  the  necessity 
hasn’t  been  seen  before,  often  by  not  perceiving  the  problem  in  time  as  a  problem  that 
had  to  be  dealt  with.  The  similarity  between  two  military  operations  is  often  minimal. 
New  partners  and  allies  from  other  nations  are  joining  in,  all  bringing  with  them  their 
own  doctrine  and  their  supporting  equipment.  New  organizations  are  joining  us  that  do 
not  know  how  the  military  decision  process  is  working,  and  sometimes  there  is  even  the 
fear  to  be  run  over  by  the  hierarchically  structured  and  well-organized  command  chains 
of  the  military  partner,  so  confidence  building  may  become  an  issue.  All  these 
developments  and  observations  lead  to  an  increasing  necessity  to  have  a  model  of  the 
C4ISR  processes  to  be  used  within  the  coalition  at  hand  that  can  be  used  to  support  the 
communication  between  the  different  partners. 

The  models  can  be  used  to  create  a  better  understanding  of  what  the  respective  sides  are 
normally  doing  and  are  capable  of  doing  finally  leading  to  become  the  basis  necessary  to 
create  interoperable  federated  Information  Technology  (IT)  solutions  supporting  the  new 
process. 

In  modem  coalition  based  military  operations,  the  Command  and  Control  (C2)  process  is 
not  limited  to  the  C4ISR  elements  known  from  the  traditional  scenarios  of  defense 
operations  based  on  the  use  of  military  force.  Modem  C2  seems  to  become  increasingly 
challenging  and  is  comparable  to  the  management  of  a  very  complex  business  process. 
Consequently,  IT  solutions  supporting  business  managers  are  at  least  good  idea 
generators  when  looking  for  IT  supporting  the  C2  process  and  the  C4ISR  domain.  In  this 
context,  among  the  benefits  of  process  modeling  are  the  following  ones,  which  are 
derived  from  the  benefits  of  business  process  modeling  as  described  in  [7]  and  modified 
to  be  applicable  in  the  C4ISR  context: 

1.  Models  help  the  decision  makers  to  understand  the  key  mechanisms  of  an 
existing  process.  A  model  provides  a  clear  picture  of  acting  entities,  roles, 
relations,  and  tasks.  This  is  needed  to  understand  the  processes  of  the  allies  as 
well  as  the  processes  of  the  non-military  partners  and  vice  versa. 

2.  Models  act  as  the  basis  for  creating  suitable  information  systems  that  support 
the  process.  The  model  comprises  descriptions  of  process  that  can  be  used  to 
identify  necessary  support.  Furthermore,  the  sub-processes  already  supported  by 
IT  in  the  various  participating  organizations  are  displayed,  including  the 
interfaces  of  the  systems  as  well  as  their  information  capability  in  the  sense  of 
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available  information  that  can  be  delivered  to  other  systems  as  well  as  suitable 
information  that  can  be  computed  to  deliver  new  insights.  Therefore,  the  model 
can  serve  to  place  the  various  existing  systems  into  their  place  with  the  federated 
system  of  systems  supporting  the  overarching  operations  and  also  serves  as  the 
requirement  driver  for  additional  IT  support. 

3.  Models  can  be  used  to  improve  the  current  structure  and  operation.  By  creating 
a  common  description  of  the  overall  operation  and  participating  organizations  and 
supporting  systems,  redundancies  as  well  as  bottlenecks  become  obvious. 
Necessary  changes  can  be  identified  and  solutions  can  be  derived  and  agreed  on 
based  on  the  common  model. 

4.  Models  show  the  structure  of  innovated  solutions.  The  model  becomes  also  the 
basis  for  a  common  action  plan  supporting  radical  as  well  as  incremental  changes. 
The  desired  end  state  and  the  necessary  steps  leading  from  the  status  quo  to  this 
end  state  are  part  of  the  model.  The  model  itself  therefore  becomes  an  important 
management  instrument  to  orchestrate  the  necessary  improvements  in  parallel  and 
distributed  events. 

5.  Models  can  serve  as  a  basis  to  evaluate  new  ideas,  to  copy  other  structures,  and 
to  evaluate  processes  used  by  neutral  or  hostile  entities  of  the  environment  in 
which  the  operation  takes  place.  As  the  model  comprises  the  necessary  detail 
needed  to  derive  a  conceptual  or  functional  model  of  the  mission  space,  support 
by  Modeling  and  Simulation  (M&S)  directly  becomes  possible.  Respective 
experiments,  like  for  example  conducted  under  the  aegis  of  TRAC  for  the  Army 
in  particular,  or  under  the  aegis  of  USJFCOM  J9  for  the  armed  forces  in  general, 
can  help  to  evaluate  such  future  concepts.  An  appropriate  model  can  be  used  to 
orchestrate  respective  efforts  and  helps  to  create  a  common  understanding  of  all 
participating  institutions. 

6.  Models  facilitate  the  identification  of  potential  reuse  of  existing  solutions. 
Although  every  operation  is  special  and  unique,  many  processes  exists  that  can  be 
supported  by  standard  solutions.  Additionally,  when  using  a  common  model  to 
do  so,  the  identification  of  processes  having  been  supported  in  other  operations 
and  that  can  be  modified  easily  to  support  the  actual  process  becomes  feasible 
with  minimal  effort. 

This  excursus  should  emphasize  the  potential  contributions  of  models  to  deal  with 
interoperability  above  the  information  level.  If  all  participants  share  the  same  model  of 
the  operation,  this  model  can  be  used  to  map  the  supporting  IT  processes  even  if  the 
underlying  IT  systems  are  not  technically  interoperable  on  the  highest  possible  level. 

Form  his  experience  in  various  international  projects  the  author  concludes  that  technical 
reference  models  dealing  with  the  modeling  process  are  of  tremendous  value.  When 
choosing  the  right  technical  framework  to  support  the  modeling  of  C4ISR  relevant 
processes,  a  tremendous  benefit  for  the  Warfighter  being  supported  can  be  achieved. 
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Under  the  aegis  of  the  Object  Model  Group  (OMG),  a  commercial  consortium 
comprising  over  800  professional  IT  companies,  actually  develops  the  “Model  Driven 
Architecture,”  which  places  the  modeling  process  in  the  center  of  IT  support  to  gain 
maximize  interoperability  and  flexibility  [9],  The  authors  assumes  that  the  evaluation  of 
this  approach  will  positively  influence  the  ideas  of  coalition  interoperability  and 
furthermore  can  drive  new  requirements  and  related  solutions  for  future  C4ISR  systems, 
which  themselves  would  be  beyond  actual  stovepipe  solutions.  In  particular,  the  new 
architecture  Global  Information  Grid  (GIG)  Enterprise  Services  (GES)  under 
development  by  the  U.S.  Defense  Information  Systems  Agency  (DISA)  to  become  the 
technical  backbone  of  the  GIG,  and  hence  enabling  technical  interoperability  for  NCW 
operations,  will  be  influenced  by  MDA-related  developments. 

3.2  Using  UML  for  Modeling  for  Interoperability 

The  questions  remains,  which  technical  framework  to  support  the  scientific  modeling 
process  to  use.  In  particular  in  the  IT  domain,  legions  of  suppliers  of  technical  solutions 
are  involved.  However,  the  IT  industry  is  more  and  more  following  standards. 

One  of  the  most  important  developments  of  recent  years  within  the  commercial  software 
development  is  the  broad  acceptance  of  the  Unified  Modeling  Language  (UML)  as  a 
standard  way  to  describe  software  solutions.  Since  having  been  standardized  by  the 
Object  Management  Group  (OMG)  in  1997,  it  has  become  of  interest  to  management 
consulting  firms,  business  analysts,  system  analysts,  software  developers,  and 
programmers  [10].  As  already  pointed  out,  it  can  be  seen  as  the  standard  for  blueprints  of 
software  solutions  [7].  Over  the  last  years,  the  UML  became  something  like  the  lingua 
franca  for  modeling  purposes. 

For  those  readers  knowing  the  C4ISR  Architecture  Framework  [2]  -  or  within  NATO  its 
counterpart:  NATO  C3  Systems  Architecture  Framework  [8]  -  it  is  worth  mentioning  that 
most  of  the  products  defined  to  model  the  three  different  views  of  an  architecture  - 
operational  view,  systems  view,  and  technical  view  -  can  be  mapped  to  UML  products. 
This  applicability  of  a  common  standard  facilitates  to  bridge  the  gap  between  the 
Warfighter  and  the  (C4ISR)  system  designer.  It  also  shows  that  the  modeling  results 
based  on  the  C4ISR  Architecture  Framework  -  and  the  C4I  Support  Plans,  which  are  a 
subset  of  the  former  -  can  be  reused  in  the  more  general  UML  environment. 

Actually,  several  groups  are  working  on  enhancements  of  the  UML  for  special 
application  domains.  The  enhancements  will  be  standardized  under  aegis  of  the  OMG 
consortium. 

Based  on  the  success  story  of  UML  for  modeling,  the  OMG  consortium  started  the  Model 
Driven  Architecture  (MDA)  project.  The  MDA  is  based  on  this  idea  of  meta-modeling. 
It  merges  the  different  OMG  standards  having  been  developed  and  used  separately  so  far 
into  a  common  view  by  applying  common  meta  models  to  them.  Without  going  into 
details,  just  a  view  of  these  standards  that  will  become  part  of  the  MDA  should  be 
mentioned:  the  Extensible  Markup  Language  (XML)  and  the  XML  Metadata  Interchange 
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specification  (XMI),  the  Unified  Modeling  Language  (UML),  middleware  solutions 
supporting  CORE  A,  Sun’s  Enterprise  JavaBeans,  or  Microsoft’s  DOTNET,  the  Common 
Warehouse  Metamodel  (CWM),  the  Meta  Object  Facility  (MOF),  and  many  more.  The 
kernel  idea  is  to  use  a  common  stable  model,  which  is  language-,  vendor-  and 
middleware-neutral.  This  model  must  be  a  meta-model  of  the  concept.  The  MDA  offers 
concepts  for  such  a  model.  With  such  a  model  in  the  center,  users  having  adopted  the 
MDA  gain  the  ability  to  derive  code  for  various  sub-levels.  Even  if  the  underlying 
infrastructure  shifts  over  time,  the  meta-model  remains  stable  and  can  be  used  to  support 
various  middleware  implementations  based  on  multiple  languages,  vendors,  and 
platforms.  To  be  able  to  do  so,  the  MDA  defines  an  approach  to  system  specifications 
that  separates  the  specification  of  the  system  functionality  from  the  specification  of  the 
platform  specific  implementation.  The  following  picture  shows  a  high-level  view  on  the 
MDA. 


Figure  3:  Top-Level  View  on  the  Model  Driven  Architecture 

This  idea  can  easily  be  transferred  to  coalition  interoperability  issues.  The  coalition 
operation  is  based  on  a  common  model  of  the  operation.  This  model  is  supported  by 
various  C4ISR  systems  and  procedures  (not  limited  to  the  IT  domain)  of  the  participating 
coalition  partners.  The  resulting  system  of  systems  is  than  conducting  the  operation, 
which  itself  lies  in  one  of  the  operation  domains.  Using  this  idea,  the  technical 
middleware  standards  (such  as  CORBA  and  XML/SOAP)  in  Figure  3  are  replaced  by  the 
supporting  organizational  interpretations  (including  IT  support)  to  be  applied  in  an 
operational  context. 
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In  summary,  the  common  model  of  the  operation  must  be  the  goal  of  coalition 
interoperability.  C4ISR  systems  and  the  related  technical  interoperability  is  only  a 
contribution  to  the  overall  solution.  The  author  is  convinced  that  C4ISR  systems  can  be 
improved  to  support  this  idea  of  a  “common  operational  model”  instead  of  a  “common 
operational  picture”  in  particular  by  integrating  M&S  systems.  However,  coping  with 
this  related  theme  in  technical  detail  lies  beyond  the  scope  of  the  paper. 

4  Examples  for  applicable  Measure  of  Merits 

The  last  section  motivated  that  coalition  interoperability  is  based  on  a  common  model  of 
the  operation,  which  includes  a  common  interpretation  of  this  model.  This  section 
presents  some  examples  of  existing  metrics  and  measures  of  merits.  They  helped  to 
formulate  the  proposed  reference  framework  of  coalition  interoperability  and  many  of  the 
ideas  are  reflected  in  the  proposal 

4. 1  NA  T O  Code  of  Best  Practice  for  C2  Assessment 

In  1999,  NATO  published  a  first  version  of  a  Code  of  Best  Practice  (NCOBP)  for 
Command  and  Control  (C2)  Assessment  that  is  focused  on  Article  V  operations,  i.e.,  the 
analysis  of  ground  forces  at  a  tactical  echelon  in  mid-  to  high-intensity  conflict.  It  does 
not  cover  the  extended  mission  spectrum  of  the  alliance  and  the  associated  issues. 
Therefore,  the  NATO  Research  and  Technology  Organization  (RTO)  initiated  a  follow- 
on  action  tasking  the  expert  group  SAS-026  to  develop  a  new  version  of  the  NCOBP  that 
was  to  focus  on  operations  other  than  war  (OOTW)  and  the  impact  of  significantly 
improved  information  technology  and  its  implications  for  military  organizations  and 
operations.  The  resulting  revision  [1 1]  was  published  in  2002. 

The  term  C2  is  intended  to  be  an  umbrella  term  that  encompasses  the  concepts,  issues 
organizations,  activities,  processes,  and  systems  associated  with  the  NATO  definition. 
C2  is  defined  as  “the  organization,  process,  procedures,  and  systems  necessary  to  allow 
timely  political  and  military  decision  making  and  to  enable  military  commanders  to  direct 
and  control  military  forces."  This  definition  includes  headquarters,  facilities, 
communications,  information  systems,  and  sensors  &  warning  installations.  Within  the 
NCOBP,  military  operations  beyond  the  limits  of  Article  V  are  characterized  by 
multilateral  dynamics  including  interactions  not  only  between  friendly  and  adversary 
forces  but  with  other  actors  as  well  such  as,  for  example,  Non-Governmental 
Organizations  (NGO),  Private  Volunteer  Organizations  (PVO),  International 
Organizations  (10),  international  corporations,  transnational,  sub-national,  criminal,  and 
other  organizations.  In  addition,  they  involve  action-reaction  dynamics  characterized  by 
the  impact  of  interacting  soft  elements  such  as  culture,  morale,  doctrine,  training,  and 
experience.  The  revision  of  the  NCOBP  represents  both,  an  improvement  of  the  original 
code  based  on  evidence  collected  during  applications  and  an  extension  to  account  for  the 
new  mission  spectrum  and  new  information-related  capabilities  and  emphasizing  in 
particular  human  issues  that  arise  in  conjunction  with  inhomogeneous  attributes  and 
diverse  motivations  of  the  parties  involved.  All  chapters  underwent  a  complete  review. 
Chapter  5  of  the  NCOBP  is  explicitly  dealing  with  Measures  of  Merits  (MoM). 
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Recognizing  the  difficulties  experienced  in  C2  assessments  in  specifying  appropriate 
measures  of  effectiveness,  the  1992  final  report  of  the  NATO  Research  Study  Group 
AC/243  Panel  7  Ad  Hoc  Working  Group  (AHWG)  on  the  ‘Impact  of  C3I  on  the 
Battlefield’  recommended  that  a  hierarchy  of  measures  be  established  as  an  important 
step  in  understanding  overall  system  effectiveness.  This  Hierarchy  allowed  that  systems 
be  analyzed  at  different  levels  of  detail.  Similar  recommendations  have  been  made  by 
other  institutions  such  as  the  Military  Operations  Research  Society  (MORS).  The 
NCOBP  builds  on  these  ideas.  With  a  view  to  OOTW,  an  extended  hierarchy  is  proposed 
to  characterize  the  contribution  of  military  actions  to  broader  policy  societal  outcomes. 
The  following  five  levels  of  MoM  have  been  adopted: 

•  Measures  of  Policy  Effectiveness  (MoPE)  which  focus  on  policy  societal 
outcomes; 

•  Measures  of  Force  Effectiveness  (MoFE)  which  focus  on  how  a  force 
performs  its  mission  or  the  degree  to  which  it  meets  its  objectives; 

•  Measures  of  C2  Effectiveness  (MoCE)  which  focus  on  the  impact  of  C2 
systems  within  the  operational  context; 

•  Measures  of  Performance  (MoP)  which  focus  on  internal  system  structure, 
characteristics  and  behavior;  Performance  measures  of  a  system  may  be 
reduced  to  measures  based  on  time,  accuracy,  capacity  or  a  combination  that 
may  be  interdependent; 

•  Dimensional  Parameters  (DP)  that  are  the  properties  or  characteristics 
inherent  in  the  physical  C2  systems. 

In  addition  to  the  hierarchy,  the  NCOBP  provides  examples  and  discusses  applications  of 
MoM  on  all  levels.  It  also  deals  with  the  question  of  how  to  measure  MoM  and  what 
criteria  may  be  useful  for  assessing  validity,  reliability,  practicality,  and  utility  of  MoM. 
Table  1  gives  some  examples  for  measures  of  performance  (MoP)  and  measures  of  C2 
effectiveness  (MoCE). 

While  dimensional  parameters,  measures  of  performance,  and  measures  of  C2 
effectiveness  can  be  seen  as  belonging  into  the  domain  of  technical  interoperability,  the 
measures  of  force  effectiveness  and  measures  of  political  effectiveness  belong  into  the 
organizational  interoperability  section.  However,  the  measure  proposed  here  are  mainly 
used  to  measure  the  effect  of  an  operation.  Although  it  can  be  argued  that  an  operations 
based  on  interoperable  solutions  generally  is  more  effective  and  more  efficient,  hence, 
improving  the  efficiency  can  be  seen  as  a  hint  for  higher  interoperability,  the  challenge  to 
deal  with  various  levels  of  interoperability  is  only  partially  met  in  the  NCOBP. 
Therefore,  the  MoM  hierarchy  can  be  used,  but  it  has  to  be  extended.  It  has  to  be  ensured 
that  the  resulting  measures  are  meeting  the  criteria  for  MoM,  i.e.,  validity,  reliability,  and 
credibility. 
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Table  1:  Examples  for  MoP  and  MoCE  (see  [11]) 


MoPs  Technical  Services  Attributes  -  Hardware  and  Software  | 

Availability 

Functional  capabilities  available  to  users 

Survivability 

Ability  to  survive  partial  destruction  of  system 

Robustness/Endurance 

Ability  to  adapt  to  environment 

Maintainability 

Ease  of  repair  or  replacement  during  operation 

Computation  Capacity 

Acceptable  response  times  to  users 

Portability 

Ability  to  operate  on  different  platforms 

Mobility 

Ability  to  move  with  operational  units 

MoPs  Technical  Services  -  Applications  Attributes  | 

Interoperability 

Communications  with  other  C2  systems 

Security 

Confidentiality  and  integrity  of  data 

Confidentiality 

Information  protected  at  appropriate  level 

Integrity 

Required  for  confidence  of  data 

Customizability 

Ability  to  customize  parameters  to  actual  activities 

Quantity  of  Information 

Provide  all  information  required  by  user 

Bandwidth 

Ability  to  support  multi-media 

MoCEs  User  Effectiveness  -  Information  Quality  | 

Selectivity 

Ability  to  provide  required  information  in  required  amount 

Accuracy 

The  extent  to  which  true  values  are  approached 

Comprehension 

Facilitate  understanding  of  situation 

MoCEs  User  Effectiveness  -  Time  Related  | 

Response  time 

Response  to  requests  within  established  times 

Timeliness 

Information  available  at  appropriate  time 

Ease  of  use 

Ease  of  access  to  information 

Training  time 

Time  to  train  users 

Decision  response  time 

Time  available  to  commanders 

4.2  Code  of  Best  Practice  for  Experimentation 

Very  closely  related  to  the  NCOBP  is  the  Code  of  Best  Practice  for  Experimentation 
(COBPE)  [12],  It  was  developed  using  the  experiences  and  results  gained  from  the 
NCOBP  related  work,  but  it  focuses  on  the  efficiency  of  transformation  experiments. 
Information  age  transformation  processes  are  perceived  to  be  highly  influenced  by 
technical  and  organizational  -  hence  also  coalition  -  interoperability  issue.  It  therefore 
seems  to  be  worthwhile  to  analyze  the  sections  of  the  COBPE  dealing  with  measures  of 
merits,  i.e.,  in  particular  chapter  7  and  appendices  A  and  B  -  a  little  bit  closer.  As  the 
NCOBP,  the  COBPE  stresses  the  necessity  that  all  measures  are  fulfilling  the  criteria  of 
validity,  reliability,  and  credibility.  Two  examples  are  given  in  the  COBPE  that  are 
directly  applicable  to  the  problem  dealt  with  in  this  paper,  the  Network  Centric  Warfare 
Value  Chain  and  the  Effects-Oriented  Measures  and  Metrics. 

4.2.1  The  Network  Centric  Warfare  Value  Chain 

The  Network  Centric  Warfare  value  chain  approach  employs  several  layered  concepts, 
which  can  be  related  to  the  necessary  levels  of  technical  and  organizational 
interoperability: 

•  The  value  chain  starts  with  Data  Quality  describing  the  information  within  the 
underlying  command  and  control  systems. 
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•  Information  Quality  tracks  the  completeness,  correctness,  currency,  consistency, 
and  precision  of  the  data  items  and  information  statements  available. 

•  Knowledge  Quality  deals  with  procedural  knowledge  and  information  embedded 
in  the  command  and  control  system  such  as  templates  for  adversary  forces, 
assumptions  about  entities  such  as  ranges  and  weapons,  and  doctrinal 
assumptions,  often  coded  as  rules.  In  future  systems,  this  agile  component  could 
be  presented  by  M&S  systems.  Knowledge  quality  is  the  first  component  related 
to  the  common  model  of  the  operation. 

•  Finally,  Awareness  Quality  measure  the  degree  of  using  the  information  and 
knowledge  embedded  within  the  command  and  control  system.  Awareness  is 
explicitly  placed  in  the  cognitive  domain,  i.e.,  definitely  above  the  level  of 
technical  interoperability. 

Taken  together,  data,  information,  knowledge,  and  awareness  can  be  used  to  measure  the 
ability  to  conduct  coalition  operations,  i.e.,  they  can  be  used  to  deal  with  the  various 
levels  of  interoperability.  The  technical  levels  describe  the  ability  to  share  data, 
information,  knowledge,  and  awareness.  Due  to  the  COBPE,  shared  information  and 
knowledge  can  be  measured  in  almost  exactly  the  same  way  as  individual  information 
and  knowledge  (completeness,  correctness,  currency,  consistency,  and  precision),  but 
additional  dimensions  must  be  considered.  Examples  for  these  new  dimensions  are 
questions  such  as 

•  What  fractions  of  the  relevant  command  and  control  system  users  have 
access? 

•  What  delays  may  occur  in  that  access? 

•  How  well  is  the  total  system  informed  (what  is  known  to  the  members)? 

•  How  well  the  typical  (average  or  median)  user  is  informed? 

It  becomes  obvious  that  the  border  between  technical  and  organizational  levels  is  fluent. 
As  stated  earlier,  a  well-informed  decision  maker  may  come  -  due  to  his  cultural 
background  -  to  a  complete  different  set  of  decision  that  his  coalition  partner  using  the 
exact  same  information  based  on  totally  interoperable  systems.  On  the  other  hand,  two 
culturally  similar  educated  decision  makers  may  use  systems  that  are  hardly 
interoperable,  delivering  various  views  on  the  situation,  but  may  still  be  able  to 
coordinate  their  efforts  towards  a  common  goal.  They  overrule,  so  to  say,  the  technical 
level  of  non-interoperability  with  organizational  skills. 

In  summary,  the  Network  Centric  Warfare  value  chain  provides  a  valuable  source  to 
analyze  the  various  layers  and  levels  of  interoperability.  The  MoM  hierarchy  defined  by 
the  NCOBP  is  explicitly  referred  to.  The  symbiosis  of  NCOBP  and  COBPE  can  be 
directly  mapped  to  the  last  technical  reference  model,  the  metrics  for  Network  Centric 
Warfare. 


15 


A.  Tolk:  Beyond  Technical  Interoperability 


8"'  CCRTS,  National  Defense  University, 
Washington,  D.C.,  June  2003 


4.3  Metrics  for  Network  Centric  Warfare 

With  the  introduction  of  the  ideas  of  Network  Centric  Warfare  (NCW),  the  ideas  of 
interoperability  for  coalition  operations  definitely  were  leveled  above  the  technical 
interoperability.  In  [13],  Alberts  et  al.  are  proposing  the  following  five  level  hierarchy  of 
measures: 

•  Level  1 :  Measures  of  Infrastructure  Performance 

•  Level  2:  Measures  of  Battle  Sphere  Awareness 

•  Level  3:  Measures  of  Battle  Sphere  Knowledge 

•  Level  4:  Measures  of  Exploiting  Battle  Sphere  Knowledge 

•  Level  5:  Measures  of  Military  Utility 

Also  the  human  and  organizational  issues  are  taking  much  more  into  account  than  it  was 
done  before,  e.g.,  by  evaluating  reaction  time,  expertise,  leadership,  motivation,  etc. 
These  ideas  were  reflected  in  various  papers  during  the  recent  Command  and  Control 
Research  and  Development  Symposia.  A  very  good  summary  on  related  proposals  was 
given  during  a  guest  lecture  at  the  Virginia  Modeling  Analysis  and  Simulation  Center 
(VMASC)  in  Spring  2003  [14].  The  resulting  framework  in  given  in  Figure  4. 
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Figure  4:  Network  Centric  Warfare  Metrics  Framework 
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We  have  to  distinguish  three  various  domains,  namely  the  physical  domain,  the  cognitive 
domain,  and  the  information  domain.  There  is  a  fourth  domain  mentioned  that  overlaps 
and  influences  parts  of  the  information  and  cognitive  domain:  the  social  domain.  The 
domain  can  be  interpreted  as  follows: 

•  The  technical  backbone  collecting,  computing,  distributing  and  disseminating  the 
data  and  producing  information  is  measured  by  metrics  of  the  information 
domain.  Parts  are  already  affected  by  human  and  organizational  issues,  such  as 
the  degree  of  shared  information.  These  metrics  also  belong  to  the  social  domain. 

•  The  interpretation  of  the  information  in  the  value  chain  of  NCW  belongs  to  the 
cognitive  domain.  While  some  of  the  metrics  are  individual  metrics,  the 
organizational  issues  are  comprised  in  the  social  domain  as  well. 

•  Finally,  the  effects  in  the  battle  sphere  belong  to  the  physical  domain.  These  are 
the  metrics  traditionally  used  to  evaluate  the  success  or  failure  of  military 
operations. 

This  framework  depicts  the  interplay  of  technical  and  organizational  interoperability  on 
the  way  to  coalition  interoperability  very  well.  However,  as  before,  the  metrics  are 
operation  centric,  i.e.,  the  various  levels  of  interoperability  are  still  hidden. 

5  The  Reference  Model  of  Interoperability 

To  deal  with  the  various  levels  of  interoperability  explicitly,  the  framework  shown  in 
Figure  5  is  proposed.  The  author  is  well  aware  of  the  fact  that  this  is  just  one  dimension 
of  coalition  interoperability;  however,  the  proposed  view  helps  to  facilitate  the  discussion 
on  technical  and  organizational  support  in  case  of  absence  of  interoperable  solutions.  It 
is  seen  as  being  complementary  to  the  frameworks  dealt  with  above.  It  is  not  intended  to 
be  a  universal  replacement.  However,  the  framework  will  help  to  formulate  layered 
models  that  can  gradually  be  implemented  and  supported  by  organizational  as  well  as 
technical  facilitators  in  a  way  it  wasn’t  possible  before.  In  particular  when  looking  at  the 
potential  support  of  the  C4ISR  processes  dealing  with  NCW  based  on  common  models  of 
the  operations  as  proposed  in  section  3.1  and  the  technical  implications  presented  in 
section  3.2,  this  additional  view  can  facilitate  the  support. 

The  lower  levels  deal  with  the  layers  of  technical  interoperability,  i.e.,  the  ability  to 
collect,  manipulate,  distribute,  and  disseminate  data  and  information.  In  addition  to 
handling  data  and  information,  knowledge  presentation  in  form  of  procedures  and 
implemented  models  and  awareness  support  by  respective  presentation  methods  is  part  of 
the  value  chain. 

The  knowledge/awareness  layer  actually  is  a  fluent  transition  from  technical 
interoperability  supported  by  the  C4ISR  systems,  such  as  the  GIG,  to  organizational 
interoperability  layers  dealing  with  the  harmonization  and  coordination  of  related 
coalition  NCW  operations. 
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Figure  5:  The  Layers  of  Coalition  Interoperability 

It  is  obvious  that  coalition  interoperability  can  be  maximized  by  reaching  maximum 
interoperability  ratings  on  all  levels.  However,  it  is  not  obvious  without  further 
evaluation,  which  of  the  levels  will  contribute  to  what  extend  to  the  overall  goal  of 
coalition  interoperability.  In  order  to  find  this  out,  questions  as  the  following  ones  can 
have  to  be  answered  (grouped  by  the  recommended  layers): 

•  Physical  Interoperability 

o  Is  the  system  a  stand-alone  solution? 

o  Can  a  procedure  for  data/information  exchange  be  established  (such  as 
exchange  of  magnet  tapes,  disks,  etc.)? 
o  Is  the  system  physically  connected  to  the  C4ISR  network? 

•  Protocol  Interoperability 

o  What  communication  protocols  are  supported  on  the  C4ISR  network? 
o  What  kind  of  media  suitable  for  data/information  exchange  can  be  read 
and  analyzed? 

•  Data/Object  Model  Interoperability 

o  Are  standardized  data  element  used  for  the  data/information  exchange? 
o  Are  (self-)  explaining  meta  data  available  with  the  data  that  allow  the 
mapping  of  the  exchanged  data  elements  to  the  data  elements  used  in  the 
participating  systems? 
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o  Are  Data  Management  Agencies  established  that  are  aware  of  the  data  and 
information  presentation  of  the  participating  systems? 
o  Is  the  meta  data  used  to  describe  data  and  information  standardized? 

•  Information  Interoperability 

o  Can  the  procedures  and  models  used  to  represent  dynamical  information 
mapped  to  each  other? 

o  Are  the  cause-effect-chains  of  the  models  presenting  the  information 
comparable?  Can  they  be  harmonized? 

•  Knowledge/Awareness 

o  Is  a  common  operational  picture  supported? 

o  Is  the  agility  of  the  battle  sphere  supported,  e.g.,  by  supporting  M&S 
routines  for  courses-of-action  analyses? 
o  Are  collaboration  tools  and  collaborative  environments  supported,  such  as 
workflow  management,  tele-  and  videoconferencing,  etc? 
o  Are  various  views  on  the  operation  supported?  Are  these  views 
harmonized  and  coordinated? 

•  Aligned  Procedures 

o  Are  the  Rules-of-Engagements  aligned  within  the  tactical  levels  of  the 
operations? 

o  Are  the  tactics  available  in  the  form  of  military  field  manuals? 
o  Are  the  field  manuals  supported  by  data  or  knowledge  bases? 
o  Are  models  or  simulation  systems  available  implementing  the  tactical 
procedures? 

o  Is  a  communication  infrastructure  on  the  tactical  level  established? 

•  Aligned  Operations 

o  Are  the  interoperability  issues  for  aligned  procedures  applicable  on  the 
tactical/operational  level? 

o  Are  the  military  leaders  and  decision  makers  aware  of  the  processes  of  the 
coalition  partners,  e.g.,  through  exchange  programs  of  the  military 
academies,  cultural  and  political  exchange  programs,  etc? 

•  Harmonized  Strategy/Doctrines 

o  Are  the  interoperability  issues  for  aligned  operations  applicable  on  the 
strategic  level? 

o  Are  the  cultural  and  social  backgrounds  of  the  partners  aligned? 

•  Political  Objectives 

o  Do  the  partners  share  the  same  political  values? 

o  Are  the  ethical  backgrounds  of  the  partners  aligned? 

o  Are  the  partners  aware  of  the  political  objectives  of  the  coalition? 

To  deal  with  the  complete  process,  the  value  chain  of  NCW  has  to  be  analyzed  as  another 
dimension  of  the  problem.  The  political  effectiveness  and  the  related  MoM  hierarchy  as 
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proposed  by  the  NCOBP  is  another  one.  Taken  together,  this  “Cube  of  NCW  Metrics” 
seems  to  be  more  adequate  to  deal  with  the  challenge  than  the  one-dimensional  proposals 
published  so  far. 

What  the  author  hopes  to  have  shown  is  the  necessity  to  use  models  for  interoperability 
solutions.  The  arguments  given  in  section  3.1  can  be  applied  to  every  level  of 
interoperability  above  the  physical  interoperability.  Within  the  M&S  community,  the 
idea  starts  getting  ground  that  standards  for  meaningful  interoperability  must  target  the 
modeling  level  (common  conceptual  modeling,  application  of  the  MDA,  behavior 
description  of  components  as  part  of  the  necessary  documentation  for  Base  Object 
Models,  etc.).  Standards  targeting  the  implementation  level  are  aiming  to  short.  The 
same  thing  is  true  for  the  C4ISR  community.  After  having  focused  on  common  data 
models  and  information  exchange  requirements  as  the  basis  for  interoperability,  meta 
data  and  data  management  are  slowly  moving  into  the  center  of  interest.  Meta  data  and 
data  management  in  the  context  of  dynamical  and  agile  systems  is  nothing  but  adding 
information  about  the  source  of  data  and  the  context  of  applicability.  This,  however,  is 
nothing  but  connecting  the  data  to  an  underlying  concept  -  or  model  -  of  the  operation. 
The  necessary  step  to  support  interoperability  is  to  level  this  meta  data  activities  from  the 
actual  basis  of  often  poorly  documented  “common  sense”  to  a  standardized  way  of 
conceptual  modeling,  in  other  words  transforming  it  from  free  art  to  engineering  and 
science. 

The  only  recently  released  DoD  Net-Centric  Data  Strategy  [15]  is  addressing  the  issue 
explicitly  in  DoD  Data  Goal  4:  “Enable  Data  to  be  understandable,”  i.e.,  users  and 
applications  can  comprehend  the  data,  both  structurally  and  semantically,  and  readily 
determine  how  the  data  may  be  used  for  their  specific  needs.  This,  however,  is  the  goal 
of  the  approach  described  hare  as  well.  The  proposed  framework  is  not  a  solution,  but 
can  give  some  guidance. 

6  Summary 

The  question  may  arise:  What  is  such  a  reference  model  for  interoperability  beyond 
technical  systems  good  for?  The  author  perceives  it  to  be  very  necessary  for  various 
reasons,  such  as 

•  Using  the  same  reference  model,  various  Military  Operations  Research  studies 
become  comparable.  In  particular  in  early  stages,  the  use  of  standardized 
methods  in  research  is  often  perceived  to  be  counterproductive  and  limited.  The 
result  is  that  such  studies  often  lead  to  tremendously  important  insights,  but  they 
are  based  on  a  rigid  method.  Results  are  hardly  reusable  or  transferable. 
Interpretation  of  the  results  may  lead  to  misinterpretations  and  misperceived 
constraints  for  a  potential  follow-on.  This  is  particularly  true  for  coalition 
interoperations,  where  technically  hardly  measurable  human  and  organizational 
factors  are  important.  The  proposed  reference  framework  can  facilitate  the 
process  of  knowledge  transfer  between  the  studies  as  well  as  the  doctrinal 
developers. 


20 


A.  Tolk:  Beyond  Technical  Interoperability 


8"'  CCRTS,  National  Defense  University, 
Washington,  D.C.,  June  2003 


•  Establishing  technical  interoperability,  in  particular  when  interoperability  comes 
as  an  aftermath  to  system  proeurement  as  it  is  most  often  the  ease  in  the  domain 
of  (international)  coalitions,  is  costly  and  time  eonsuming.  Neither  time  nor 
money  normally  ean  be  expeeted  to  be  available  for  short-term  coalition 
operations,  whieh  beeome  the  military  reality  more  often.  The  proposed 
framework  ean  help 

-  To  overeome  the  shortfalls  of  technically  interoperability  by  helping  to 
identify  organizational  means  that  ean  inerease  eoalition  interoperability  in 
the  absence  of  teehnieal  interoperability. 

-  To  identify  when  technically  interoperability  is  erueial. 

•  The  same  arguments  are  applicable  to  -  national  and  coalition  specific  - 
Procurement  as  well.  Legacy  systems  of  one  service,  whieh  are  still  in 
operational  use,  and  systems  of  other  services  are  rarely  harmonized  with  joint 
requirements.  Using  the  reference  model  it  will  be  possible  to  deeide,  which 
systems  have  to  be  teehnically  interoperable  and  what  systems  can  be  integrated 
organizationally  as  well. 

The  referenee  model  as  proposed  in  seetion  5  is  still  in  its  infancy  state.  However,  the 
author  pereeives  that  this  framework  is  having  the  potential  to  beeome  a  hub  for  future 
work.  It  is  recommended  to  use  the  framework  in  MORS  workshops  and  future  CCRTS 
meetings  to  fill  it  with  additional  measures  of  merit,  in  partieular  with  those  who  are 
needed  by  the  deeision  makers.  In  this  sense,  the  framework  only  is  a  start.  It  is  assumed 
that  the  proposed  framework  has  the  right  balance  between  giving  researchers  guidanee 
to  communicate  their  findings  and  freedom  to  ehoose  the  methods  and  tools  applicable  to 
solve  the  problem. 

In  addition,  the  author  hopes  that  he  was  able  to  show  that  dynamic  and  agile  capabilities 
are  needed  to  support  future  military  operations.  It  is  therefore  reeommended  to  replaee 
the  principal  of  thinking  of  a  “Common  Operational  Pieture”  with  the  vision  of  a 
“Common  Model  of  the  Operation.”  Such  models  can  be  introdueed  by  integrating  M&S 
services  into  C4ISR  systems,  but  the  details  of  this  idea  are  going  beyond  the  seope  of 
this  paper. 
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Interoperability  for  Network  Centric  Warfare 

•  Network  Centric  Warfare  (NCW) 

-  NCW  is  about  networking  humans,  organizations, 
institutions,  services,  nations,  etc. 

-  NCW  is  NOT  about  technical  networks 

-  NCW  relies  on  information  delivered 
via  the  technical  networks 

•  Working  Assumption 

-  Technical  Domain  is  important 

-  Social  and  Organizational  Component  may 
superimpose  the  Technical  Interoperability 

Coherent  Layered  Interoperability  View  is  Needed 
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Common  Operational  Models 

•  Models  help  to  understand  the  key  mechanisms  of  an 
operation 

•  Models  act  as  the  basis  for  IT  supporting  the  process 

•  Models  can  be  used  to  improve  the  current  structure  and 
operation 

•  Models  show  the  structure  of  innovated  solutions 

•  Models  can  serve  as  the  basis  to  evaluate  new  ideas  (in 
a  collaborative  manner) 

•  Models  facilitate  the  identification  of  potential  reuse 

Use  of  Models  to  get  a  common  Understanding  of  the 
Operation  (planned,  observed,  executed, ...) 
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Coalition  Technical  Reference  Model  - 

NATO  C3  TA  Reference  Model  for  Interoperability 

•  NATO’s  Reference  Model  for  Interoperability  is  embedded 
into  the  NATO  Consultation,  Command  &  Control 
Technical  Architecture  (NC3TA) 


(1)  Unstructured  Data  Exchange 

•  Network  Connectivity 

•  Document  Exchange 

(2)  Structured  Data  Exchange 

•  Network  Management 

•  Web  Access 

•  Data  Object  Exchanges 

•  Graphics  Exchange 


(3)  Seamless  Sharing  of  Data 

•  Formal  Messages 

•  Common  Data 

•  System  Management 

•  Security  and  Real  Time 

(4)  Seamless  Sharing  of  Info 

•  Common  Information  Exchange 

•  Distributed  Applications 
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How  to  insure  Interoperability  above  this  Level? 

•  Technical  Levels 

-  Physical  Connections  (incl.  Radio,  etc.) 

-  Common  Protocols 

-  Data  Elements 

-  Interfaces 

-  Documentation  of  System  Functionality 

•  Documentation  of  Functionality  is  a  Key  Factor  to  extend 
Interoperability  beyond  the  Technical  Level 

-  What  is  the  Supported  Business  Model? 

-  What  is  the  Workflow? 

-  What  is  the  Objective  to  be  reached? 
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Looking  for  the  Common  Language 

Proposal:  Unified  Modeiing  Language  (UML) 

-  Standardized  by  the  Object  Management  Group  (OMG) 

-  Developed  for  Requirement  driven  Software  Engineering 
(Use  Cases) 

-  Used  in  a  variety  of  domains 

•  Management  consulting 

•  Business  analysis 

•  Software  engineering 

(since  1997  the  de  facto  standard) 

-  Supports  other  Military  Frameworks 

•  U.S.  DoD  C4ISR  Architecture  Framework 

•  NATO  03  Systems  Architecture  Framework 
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UML  and  the  Model  Driven  Architecture  (MDA) 
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What  is  important  in  the  Model? 

Defining  Measures  of  Merit 

•  Example  I: 

The  NATO  Code  of  Best  Practice  for  Command  and 
Control  Assessment  (NCOBP) 

•  Hierarchy  of  Measures 

-  Dimensional  Parameters  (DP) 

-  Measures  of  Performance  (MoP) 

-  Measures  of  C2  Effectiveness  (MoCE) 

-  Measures  of  Force  Effectiveness  (MoFE) 

-  Measures  of  Policy  Effectiveness  (MoPE) 
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Examples  for  MoP  and  MoCE  in  the  NCOBP 

•  Measures  of  Performance 

-  Availability  (functional  capabilities  available  to  the  user) 

-  Mobility  (ability  to  move  with  operational  units) 

-  Bandwidth  (ability  to  support  applications) 


•  Measures  of  C2  Effectiveness 

-  Comprehension  (facilitates  the  understanding  of  the  situation) 

-  Selectivity  (ability  to  provide  required  info  in  required  form) 

-  Timeliness  (information  available  in  appropriate  time) 

-  Ease  of  use  (ease  of  access  to  information) 

-  Decision  Response  Time  (time  available  to  commanders) 
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The  Network  Centric  Warfare  Value  Chain 

•  Data  Quality 

-  Information  within  the  underlying  IT  system 

•  Information  Quality 

-  Completeness,  correctness,  currency,  consistency,  and 
precision  of  data 

•  Knowledge  Quality 

-  Quality  of  the  agile  components  of  IT,  such  as  procedural 
knowledge,  embedded  information,  even  embedded  M&S 
support  for  operations 

•  Awareness  Quality 

-  Degree  of  using  the  information  and  knowledge  for  the  operation 
to  improve  the  results 
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Metrics  for  Network  Centric  Warfare 

•  Five  Level  Hierarchy  for  NCW 

-  Measures  of  Infrastructure  Performance 

•  Is  the  necessary  information  (such  as  the  Common  Operational 
Picture)  available? 

-  Measures  of  Battle  Sphere  Awareness 

•  Is  the  commander  aware  of  the  single  activities  going  on? 

-  Measures  of  Battle  Sphere  Knowledge 

•  Can  this  activities  be  connected  to  an  operation  going  on? 

-  Measure  of  Exploiting  Battle  Sphere  Knowledge 

•  Can  the  commander  use  this  knowledge  to  support  the  on  planning 
and  decision  making  processes? 

-  Measures  of  Military  Utility 

•  Is  the  own  operation  supported  by  the  underlying  processes? 
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Levels  of  the  Reference  Model  for  MoM  (1/5) 

Physical  Interoperability 

•  Is  the  system  a  stand-alone  solution? 

•  Can  a  procedure  for  data/information  exchange  be  established 
(such  as  exchange  of  magnet  tapes,  disks,  etc.)? 

•  Is  the  system  physically  connected  to  the  C4ISR  network? 

Protocol  Interoperability 

•  What  communication  protocols  are  supported  on  the  C4ISR 
network? 

•  What  kind  of  media  suitable  for  data/information  exchange  can 
be  read  and  analyzed? 
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Levels  of  the  Reference  Model  for  MoM  (2/5) 

Data/Object  Model  Interoperability 

•  Are  standardized  data  element  used  for  the  data/information 
exchange? 

•  Are  (self-)  explaining  meta  data  available  with  the  data  that  allow 
the  mapping  of  the  exchanged  data  elements  to  the  data 
elements  used  in  the  participating  systems? 

•  Are  Data  Management  Agencies  established  that  are  aware  of 
the  data  and  information  presentation  of  the  participating 
systems? 

•  Is  the  meta  data  used  to  describe  data  and  information 
standardized? 

That’s  where  we  are  with  the  Net-Centric  Data  Strategy, 
U.S.  DoD  Chief  of  information  Operations,  9  May  2003 
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Levels  of  the  Reference  Model  for  MoM  (3/5) 


Information  Interoperability 

•  Can  the  procedures  and  models  used  to  represent  dynamical 
information  mapped  to  each  other? 

•  Are  the  cause-effect-chains  of  the  models  presenting  the  information 
comparable?  Can  they  be  harmonized? 

Knowledge/Awareness 

•  Is  a  common  operational  picture  supported? 

•  Is  the  agility  of  the  battle  sphere  supported,  e.g.,  by  supporting  M&S 
routines  for  courses-of-action  analyses? 

•  Are  collaboration  tools  and  collaborative  environments  supported,  such 
as  workflow  management,  tele-  and  videoconferencing,  etc? 

•  Are  various  views  on  the  operation  supported?  Are  these  views 
harmonized  and  coordinated? 

That’s  the  best  we  can  reach  by  Technical  Means 
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Levels  of  the  Reference  Model  for  MoM  (4/5) 

Aligned  Procedures 

•  Are  the  Rules-of-Engagements  aligned  within  the  tactical  levels  of  the 
operations? 

•  Are  the  tactics  available  in  the  form  of  military  field  manuals? 

•  Are  the  field  manuals  supported  by  data  or  knowledge  bases? 

•  Are  models  or  simulation  systems  available  implementing  the  tactical 
procedures? 

•  Is  a  communication  infrastructure  on  the  tactical  level  established? 

Aligned  Operations 

•  Are  the  interoperability  issues  for  aligned  procedures  applicable  on  the 
tactical/operational  level? 

•  Are  the  military  leaders  and  decision  makers  aware  of  the  processes  of 
the  coalition  partners,  e.g.,  through  exchange  programs  of  the  military 
academies,  cultural  and  political  exchange  programs,  etc? 

That’s  the  “Homework”  of  the  Military  Decision  Makers 
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Levels  of  the  Reference  Model  for  MoM  (5/5) 

Harmonized  Strategy/Doctrines 

•  Are  the  interoperability  issues  for  aligned  operations  applicable 
on  the  strategic  level? 

•  Are  the  cultural  and  social  backgrounds  of  the  partners  aligned? 
Political  Objectives 

•  Do  the  partners  share  the  same  political  values? 

•  Are  the  ethical  backgrounds  of  the  partners  aligned? 

•  Are  the  partners  aware  of  the  political  objectives  of  the  coalition? 

That’s  the  “Homework”  of  the  Policy  Decision  Makers 
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Why  Using  the  Reference  Model  for  MoM? 

•  Military  Operations  Research  Studies  become  comparable 

-  Standardized  model  documentation  facilitates  knowledge 
transfer 

•  Establishing  Technical  Interoperability  is  facilitated 

-  Interoperability  is  no  longer  the  aftermath  to  system  procurement 

-  “Build-in  Interoperability  “  is  possible 

•  Harmonization  of  Procurement  is  possible 

-  Migrating  of  legacy  systems 

-  Alignment  of  Procurement  for  Coalition  Operations 


©  2003  Andreas  Talk,  VMASC 


8.  ICCRTS  -  Track  I:  Coalition  Interoperability 


Beyond  Technical  Interoperability 


21 


Summary  and  Recommendations 

•  Reference  Model  for  MoM  is  a  Core/Hub 

-  Use  to  map  MORS  and  CCRTS  ideas 

-  To  be  filled  with  “real”  MoM,  such  as  those  needed  by 
Decision  Makers 

•  Future  IT  Systems  have  to  support  NOW 

-  Dynamic  and  agile  capabilities 

-  Integrate  M&S  functionality  into  the  Global 
Information  Grid 

-  Replace  the  “Common  Operational  Picture”  with  a 
“Common  Model  of  the  Operation” 
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